Hardware Description Languages (HDLs) are predominantly used to describe integrated circuit designs. Various HDLs exist in the market today such as Very High Speed Integrated Circuit HDL (VHDL), Verilog, and System Verilog. HDL may be used to describe a design at various levels of abstraction. For instance, VHDL supports many possible levels/styles of design description. These styles differ primarily in how closely they relate to the underlying hardware. Some levels focus more on the behavior and dataflow of a design, while other levels focus more on the structural and timing aspects of the design.
For example, integrated circuit designs may be described at the dataflow level of abstraction, often called the register transfer level (RTL). In this intermediate level of abstraction, a design is described in terms of how data moves through the design. At the heart of most digital systems today are registers, and an RTL model describes how information is passed between registers in the design. This movement is synchronized at specific points of time which are indicated by the changes of values of a special design signal commonly known as a clock. Typically, while an RTL model of the combinational logic portions of the design is described at a relatively high level, the timing and operation of registers in the design are described more specifically. RTL is therefore an intermediate level that allows the drudgery of combinational logic to be simplified (and automatically generated by logic synthesis tools) while the more important parts of the circuit, the registers, are more completely specified. Once the design is specified in an RTL model, RTL synthesis tools translate, or synthesize, this model into a still lower level model of abstraction, i.e., into a gate-level structural model. Synthesis refers to the process of transformation of a design model from a higher level of abstraction to a lower level. These transformations typically try to improve upon a set of objective metrics (e.g., area, speed, power dissipation) of a design.
Once a design has been described, the design is typically verified for proper functionality prior to physical fabrication as an integrated circuit chip. While being tested, an HDL model of a design is called a Design Under Test (DUT). This DUT (which is an RTL design model) is simulated using a testbench. The testbench generates a set of input test vectors, or stimuli, and applies the stimuli to the DUT. The testbench also reads a set of output test vectors from the DUT in response to the stimuli. The testbench collects the responses made by the DUT against a specification of correct results. A testbench in its traditional form is described at a behavioral level and defines the environment for the DUT in its target system. Behavioral HDL, which is the currently highest level of abstraction supported in HDL, describes a design in terms of what it does (or how it behaves) rather than in terms of its structural components and interconnection between them. To do so, a behavioral model specifies a relationship between signals within the design as well as inputs to and outputs from the design. When creating a behavioral model of a design, one describes the operation of the design over time. The usage of time is a critical distinction between behavioral descriptions of circuits and lower-level descriptions such as a dataflow level of abstraction.
In a behavioral description, time may be expressed precisely as absolute delays between related events (such as the propagation delays within gates and on wires), or time may be a factor by defining the sequential ordering of events. Synthesis tools currently attempt to transform behavioral HDL models into lower-level HDL models. However, synthesis tools presently do not attempt to maintain the identical behavior in actual circuitry as defined in the behavioral model. In other words, exact time sequencing of the design elements are not preserved in synthesis. Therefore, such synthesis tools can not be used for synthesizing behavioral testbenches.
Design verification may be performed using a variety of methods. For example, software based simulators are the most commonly used verification tools. Software simulators have an advantage in that they can accept HDL at any level of abstraction, such as a behavioral level of abstraction, thus providing a way to simulate both a DUT (in RTL) and its testbench (in behavioral description). However, simulators have a disadvantage in that, for large designs, simulators typically can achieve a speed of not more than a few tens to hundreds of clock cycles per second (cps).
To increase the overall simulation speed, co-simulation approaches have been used, in which the behavioral testbench runs on a software simulator and the RTL DUT is executed onto a reconfigurable hardware platform. The reconfigurable hardware platform may be implemented as, e.g., a plurality of reconfigurable hardware elements, such as a set of general-purpose processors and/or Field Programmable Gate Arrays (FPGAs).
To execute the DUT on the reconfigurable hardware platform (referred to as an emulator), the RTL model of the DUT is first translated into a structural model using an RTL synthesis tool. This structural model, known as a netlist, describes a circuit in terms of interconnection of gate level components.
The structural level, as mentioned, describes a system as a collection of logic gates and their interconnection to perform a desired function. It is a representation that is closer to the physical realization of a system. Thereafter, the emulator runs the structural level description of the DUT at the actual binary gate levels and is therefore, considerably faster than a simulator being used for the same purpose. However, the testbenches in a co-simulation approach are still written in a behavioral HDL and are run on a software platform/simulator. The emulator and the simulator have to communicate with each other in order to maintain synchronization with each other. Such frequent communication taxes the resources of the emulator and simulator, thus reducing the potential speed at which the system may operate. Because of this limitation, co-simulation speed is typically only 3 to 10 times of the software simulation speed. Co-simulation has another disadvantage that they require memories that have to be re-modeled in terms of the memories available in the emulator.